System and method for creating and rendering DICOM structured clinical reporting via the internet

ABSTRACT

The assembly and communications of a generic reporting engine for offering clinical structured reports using the Internet in an encrypted manner is provided. This method of rendering structured reports employs a DICOM Structured Reporting (SR) software database engine that maps clinical report data into a clinical structured reporting data format using a Report Editor Plug-in which is responsible for constructing the report editor GUI, for parsing the DICOM SR report to show it in the Report Editor window and to store the report content created in the GUI to the DICOM SR format. The report engine can be configured with any number of software plug-ins, so totally different ways of acquiring user input may be implemented. The current invention implements the software plug-ins using a tree-like GUI. The current implementation of this plug-in is based on DICOM SR pull model which is considered more feasible to control its presentation form, but the reporting engine allows for implementation of push model report editor plug-ins. Nothing in this novel approach to clinical reporting prevents the application from implementing a report editor from editing any DICOM SR report in a generic way, like recognizing a report from voice dictation. The Reporting Engine of the present invention provides a way for the plug-ins to recognize if they are able to open the report or not. It can be done either by software plug-ins&#39; report introspection or the process is configurable in the using the invention&#39;s reporting engine. The novel reporting engine provides a way of configuring a Report Editor Plug-in, so with one generic plug-in one may have many report templates just by configuring the plug-in. The currently implemented plug-in uses this possibility to define the report definition and GUI tree in a configuration file.

FIELD OF THE INVENTION

The present invention relates to a system and method of creating andrendering structured clinical reports over the Internet. Particularly,the present invention relates to a system and method for creating andrendering structured clinical reports, such as DICOM Structured Reports(DSR), using a Transmission Control Protocol/Internet Protocol (TCP/IP)for connecting computers to the Internet. TCP/IP is the basiccommunication protocol for the Internet. The present invention allowsusers, such as health care providers, to access diagnostic informationand render clinical reports using a computer that is connected to theInternet, or world wide web (WWW), through an encrypted connection. Theinvention permits the users to view clinical and diagnostic patientinformation over a wide area network (WAN) using a secure connectionover the Internet from any computer. The present invention uses anycomputer and does not require a traditional, designated clinicalworkstation. Traditional clinical workstations are for exclusivepurposes and have limitations in order to simply and view diagnosticmedia and static clinical reports, and then, only over a local areanetwork. Further, traditional clinical workstations and relatedinformation systems are precluded from rendering clinical structuredreports over the Internet and enabling such systems and methods.

NOTICE OF COPYRIGHT

A portion of the disclosure of this patent document contains materialsubject to copyright protection. The owner of the copyright authorizesthe reproduction of the work of authorship in the patent document or thepatent disclosure, as it appears in the Patent and Trademark Office fileor records, but otherwise reserves all copyright protections and rightswhatsoever.

BACKGROUND OF THE INVENTION

With technological advances in modern medicine, the digitaltransformation of diagnostic data for medical interpretation andanalysis has heightened the focus on clinical quality, standardizationand efficiency. In the 1990s, the Digital Imaging and Communications inMedicine (DICOM) standards were published by the American College ofRadiology and the National Electronic Manufacturers Association in orderto outline the data format, flow, and hierarchy of electronicinformation of diagnostic images and related information betweencomputer systems over TCP/IP networks. With the advances in digitalimaging and the transfer of this information over TCP/IP networks,medical professions, such as cardiology, have begun to adoptstandardized clinical reports that outline the basic content for medicalinterpretation and analysis. Organizations like the American Society ofEchocardiography (ASE) and the DICOM Standards Committee have developeda uniform structure and set of codes for the transfer ofechocardiography reporting information (DICOM Supplement 72,Echocardiography Procedure Reports, Jun. 23, 2003). The outcome of theseorganization's advancements pertaining to standardizing the transfer ofclinical information is the result of historical frustration toeffectively share data between proprietary information systems and DICOMimaging modalities (for example, ultrasound machines, X-ray machines, CTscan devices, nuclear imaging devices, etc.), such as not being able tocommunicate and transfer common measurements and information forclinical use. In many fields including medicine, veterinary medicine,and scientific manufacturing and investigation, it is necessary torender a report based on professional subjective interpretation. Due tothe amount of variance resulting in personal opinion, these reports maydiffer greatly within the same profession. As a consequence to thevariability in interpretation, organizations are establishingstandardized approaches for the creation of interpretive reports. Inmedicine, these reports prove vital in the legal, professionaldiagnostic analysis, and medical interpretation of the patient'scondition, and can further provide a basis for future assessments andongoing treatments. Whether in the hospital setting, clinical setting,physician practice, or health service setting, clinical reportingprovides a legal, confidential record of a clinician's assessment of apatient's condition.

Typically, a clinical report consists of basic clinical informationrelated to the patient's exam including but not limited to patientdemographic information, date & time of the study, performing examiner'sname, interpreting physician name(s), reimbursement code(s), studyquality, clinical assessment, medical findings, diagnostic measurements,diagnostic data, vital information, diagrams, and impressions.Contemporary methods for creating clinical reports includes performing adiagnostic exam on a patient, whereby a physician reviews the diagnosticinformation, such as digital ultrasound, and either manually documentsthe clinical findings and diagnostic impression, or the physiciandictates this basic clinical information into a recording device, suchas a Dictaphone, where it is later transcribed into a document formatthat becomes part of the patient's permanent chart. These methods eitherdelay the report processing time or limit the physician to using onlydesignated workstations solely for this purpose. These reporting methodsoften result in furthering the variability in producing accuratereports, limit the workflow, are inefficient, or are not cost effective.To confound the variability in clinical reporting, DICOM modalitiesoften utilized proprietary coding schemas for labeling the clinicalinformation, which results in complicating, if not comprising, theintegration of this data with additional information systems used bymedical professionals.

It is also important that clinical information be held confidential andsecure from unauthorized use. The Health Insurance Portability andAccountability Act (HIPAA) authorized medical professionals to protectthe confidentiality of patients' medical records, such as clinicalreports. The impact of HIPAA instituted a duty on medical professionalsto comply with these governmental standards of conduct by requiring thesecure transfer of patient data/information using secure TCP/IP networkencryption technology, like Secure Socket Layer (SSL) encryption orVirtual Private Network (VPN) techniques over public communicationnetworks. Public networks provide a cost-effective communication optionto accessing information and data over the Internet, or world-wide-web.Using TCP/IP communication protocol and encryption, like SSL or VPN,medical professionals can access clinical information, such as DICOMdata, images, media, etc. over the Internet. However, while the Internetprovides medical professionals access to this information over thepublic communications network, traditional imaging modalities along withtheir software architectures do not enable medical professionals toremotely render a clinical structured report, particularly in a DICOMStructured Report format.

As a result, physicians have turned to utilizing technologicalinnovations that depict digital diagnostic images in place of analogsystems or static radiological imagery. While these formats for medicalinterpretation are growing in medical application, these systems andmethods rely on utilizing local area networks for communicating,transmitting, and processing the digital data and medical media betweencomputers. With the expansion of health systems and the growth incompetition between physicians and hospitals over reimbursement,physicians have begun to incorporate Picture Archiving andCommunications System (PACS) into their workplace for the storage andretrieval of medical images and video. While these systems are expandingin the marketplace, most clinical reporting technologies are limited tolocal area networks and do not enable the remote rendering of clinicalstructured reports over the Internet.

Many inventors have attempted to solve these problems by allowing themedical professionals to only view a completed clinical report over theInternet using a VPN or SSL connection; these methods do not permit theuser to create and render[MK1] a DICOM Structured Report format of aclinical report over the Internet. One such method is to provide thelocal viewing of diagnostic digital images and video clips and reportrendered over a local area network whereby the user operates a viewer,such as a DICOM viewer, and a reporting software system; however in thismethod, the user generates and renders a report that is limited to onlythe LAN network architecture and not [MK2]the Internet.

Moreover, traditional DICOM imaging modalities store DICOM data inproprietary formats which often require optical character recognition(OCR) for capturing and populating measurements into reports. Thesesoftware applications perform “screen scrubbing” of the DICOM imagebitmap that contains the measurements from the static image or imageworksheet and populate the data into a database system, such asMicrosoft Excel and Microsoft Access. On the other hand, newcontemporary DICOM modalities, such as the Philips HD11 ultrasoundsystem, Philips IE33, and the GE Vivid 7, now transmit the DICOM data ina DICOM Structured Report (DSR) format based on the DICOM Supplement 72structure and format for transmitting ultrasound data and information(example, measurements). However, these technologies employ DICOM SRstandard for procedure reports only, and do not take an advantage of DSRfor creating diagnostic reports. They do not enable a user to render DSRclinical reports, build new DSR report templates (example, transthoracicechocardiography report, obstetrical report, etc.), store data obtainedfrom OCR data into the DSR format, or alter (customize) the graphicaluser interface (GUI) for creating and amending DICOM structured reports.Additionally, contemporary inventions do not combine web-viewing ofDICOM data and DICOM Structured Reports where the DICOM viewer[MK3] usesthe “Web Access to Data Objects” (WADO) protocol, which is the DICOMstandard way to access images through an Internet browser via HyperTextTransfer Protocol (HTTP), the underlying protocol used by the World WideWeb (HTTP defines how messages are formatted and transmitted, and whatactions Web servers and browsers should take in response to variouscommands).

In lieu of the technological shortcomings of these various currentlyavailable systems, there is still a need for an Internet-based softwarefor rendering structured reports, particularly DSR, in an efficient,timely manner with an easy-to-use graphical user interface.Specifically, there is a desire for a system and method for creating andrendering clinical structured reports over the Internet using anencrypted, SSL connection in accordance with DICOM standards.

It is, therefore, a feature of the present invention to provide a systemand method of creating and rendering structured clinical reports overthe Internet.

Additional features and advantages of the invention will be set forth inpart in the description which follows, and in part will become apparentfrom the description, or may be learned by practice of the invention.The features and advantages of the invention may be realized by means ofthe combinations and steps particularly pointed out in the appendedclaims.

SUMMARY OF THE INVENTION

To achieve the foregoing objects, features, and advantages and inaccordance with the purpose of the invention as embodied and broadlydescribed herein, a method for implementing a structured clinicalreporting system over the Internet is provided. The structured clinicalreport having a DICOM Structured Reporting format and the Internet isadapted to work in conjunction with Hypertext transfer protocol (HTTP)for connecting a server and multiple workstations via the Internet. Themethod comprising the steps of providing communication between aworkstation and the server via the Internet. Adapting a reporting systemto have a reporting engine in operative communication with theworkstation, an image viewer-editor and the server. Providing aworkstation for creating the clinical reports, signing the clinicalreports, rendering the clinical reports, and transmitting the clinicalreports to and from the PACS server over the Internet. The workstationhaving the capability to manipulate a study list stored on the server.Also, a picture archiving and communications system (PACS) server isprovided. Providing communication between the PACS server and a databaseserver, and providing communication between the PACS server and a viewerand the workstation over HTTP protocol. Providing communication betweenthe PACS server and the imaging modalities using a DICOM interface, suchthat the PACS server is in operative communication with the imagingmodalities over a DICOM protocol and is in operative communication withthe database. The workstation encompassing an interface viewercomprising the reporting engine, the image viewer-editor and the studylist viewer is in operative communication with the PACS server via theInternet using the HTTP protocol.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings which are incorporated in and constitute apart of the specification, illustrate a preferred embodiment of theinvention and together with the general description of the inventiongiven above and the detailed description of the preferred embodimentgiven below, serve to explain the principles of the invention.

FIG. 1 is a schematic view illustrating a preferred embodiment of aremote reporting and viewing system of the present invention.

FIG. 2 is a schematic view illustrating a preferred embodiment of thegeneral architecture of a reporting subsystem of the present invention.

FIG. 3 is a flow chart illustrating a preferred embodiment of a reportgraphical user interface sample structure of the present invention.

FIG. 4 is a schematic view illustrating a preferred embodiment of areport editor graphical user interface structure of the presentinvention.

FIG. 5 is a flow chart illustrating a preferred embodiment of a reportgraphical user interface life cycle function of the present invention.

FIG. 6 is a flow chart illustrating a preferred embodiment of astructured reporting path data structure of the present invention.

FIG. 7 is a flow chart illustrating a preferred embodiment of a reporttransforming algorithm of the present invention.

FIG. 8 is a flow chart illustrating a preferred embodiment of a reporttransforming algorithm of the present invention.

FIG. 9 is a flow chart illustrating a preferred embodiment of an Imageto DICOM Structured Report (DSR) conversion engine of the presentinvention.

The above general description and the following detailed description aremerely illustrative of the generic invention, and additional modes,advantages, and particulars of this invention will be readily suggestedto those skilled in the art without departing from the spirit and scopeof the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Reference will now be made in detail to the present preferredembodiments of the invention as described in the accompanying drawings.

FIG. 1 is a schematic view illustrating a preferred embodiment of aremote reporting and viewing system of the present invention. FIG. 1illustrates a Picture Archiving and Communications System or PACS server600 with a DICOM interface 605 for communication with imagingmodalities. However, this protocol is not suitable for the Internetbecause of firewall issues. For data exchange between a PACS server 600and a Remote Workstation 608, HTTP protocol is used. The communicationshould be encrypted using SSL and thus HTTPS protocol is used. Fordownloading images and DICOM structured reports to the remoteworkstation standard WADO interface 604 may be used. However, it doesnot provide a way for searching the data and uploading items, like forexample, images modified in workstation, or creating a structuredreport. For study list viewing and querying, a study list viewer 611 isprovided and in conjunction therewith a world-wide-web (WWW) interface610 is most suitable. Another rendition is a client-side rich clientviewer to use as a Web Services interface 603 and a database programthat executes structured query languages statements, such as JavaDatabase Connectivity (JDBC), interface 602 tunneled in Secure HTTP(HTTPS protocol), which is designed to transmit individual messagessecurely 602. So, in one embodiment, the system comprises:

1. Remote Workstation 608 comprising a Study List Viewer 611 which is apure WWW browser, and an Image Viewer/Editor 609 which is a JAVA WebStart application, or similar software plug-in, so that no manualinstallation is required, and the software updates are handledautomatically. The Remote Workstation 608 can either be a rich client ora thin client (Note: A thin client is a computer, or client, inclient-server architecture networks which depends primarily on thecentral server for processing activities. Conversely, a rich client,also known as a fat client or thick client, is a client that performsthe bulk of any data processing operations itself, but does notnecessarily rely on the server; this is the most common form of apersonal computer.). The Viewer 609 also has a reporting component whichuses a generic Reporting Engine 101 and implements the Reporting Context113 interfaces, which uses the Web Services 603 and the JDBC 602 tocommunicate with the PACS server 600.

2. PACS server 600 has the following interfaces:

(1) JDBC 601 tunneled in the HTTPS protocol 602,

(2) Web services 603,

(3) WADO 604,

(4) WWW 610, and

(5) DICOM 605.

FIG. 2 is a schematic view illustrating a preferred embodiment of thegeneral architecture of a reporting subsystem of the present invention.The general architecture of the reporting subsystem is depicted on FIG.2. The Reporting Engine 101 connects four classes of components: theReport Editor 102, the Report Renderer 103, the Report Transformer 104and the Phrase Renderer 109. It can be appreciated by those skilled inthe art that the Reporting Engine 101 can work with any number ofinstances of these classes, further referred to as software plug-ins.The software plug-ins may be developed by the PACS provider or by anindependent software vendor (ISV).

The Report Editor 102 is responsible for constructing the Report EditorGraphical User Interface GUI, for parsing the DICOM SR report in orderto show it in the Report Editor window and to store the report contentcreated in the GUI to the DICOM SR format. The Reporting Engine 101 canbe configured with any number of software plug-ins, so various ways ofacquiring user input may be implemented. The current implementation ofthis software plug-in is based on the DICOM SR pull model (Clunie, DavidA.; DICOM Structured Reporting; PixelMed Publishing, Bangor, Pa., 2001)which is considered more feasible to control its presentation form, butthe Reporting Engine 101 allows for the implementation of push modelReport Editor software plug-ins. This novel design does not prevent thepresent invention from implementing an editor for editing any DICOM SRreport in a generic way, such as recognizing a report from a reportgenerated by dictation. The Reporting Engine 101 provides a way for thesoftware plug-ins to recognize if they are able to open the report ornot. It can be done either by software plug-in report introspection orit is configured in the reporting engine. The Reporting Engine 101provides a way of configuring the Report Editor 102, so with one genericsoftware plug-in one may have many Report Templates 105 just byconfiguring the software plug-in. The currently implemented softwareplug-in uses this possibility to define the report definition and GUItree in a configuration file. Thus, the Report Template 105 used for theReport Editor 102 defines also the DICOM SR template, explicitly orimplicitly.

The Report Renderer 103 is responsible for rendering the report in aformat suitable for printing, like a portable document format (PDF). TheReporting Engine 101 provides a way to create configuration files foreach Report Renderer 103 software plug-in, so with a generic ReportRenderer 103, one may have many Report Layouts 106 that define how thereport will look like. The Reporting Engine 101 can be configured withan arbitrary number of Report Renderers 103 and Report Layouts 106. Thecurrent implementation is based on Jasper Reports. The precompiledreport files as well as the scriptlets are packed into a configurationfile that establishes a “report layout.” It uses a pull model as itprovides more control over how the report will look, but nothingprevents it from implementing a Report Renderer which will be able torender any DICOM SR report. The Reporting Engine 101 allows the ReportRenderers 103 to determine if they are able to render the report or not.It can be done either by renderer's report introspection or configuredin the Reporting Engine.

The Phrase Renderer 109 is designed to assist the Report Renderer 103 inrendering the report. While the main responsibility of the ReportRenderer 103 is to generate a report in an external format and defineits layout, the Phrase Renderer 109 generates phrases for a given nodeof a structured report (SR) tree. The phase generation can be recursiveso that the whole SR subtree of a given node is converted to a textualrepresentation; or if not, then only the given node is rendered. Phrasegeneration is always context-based which means that the Phrase Renderer109 can traverse a full SR tree apart from the node being rendered. TheReporting Engine 101 allows for the storage of configurations for thePhrase Renderer 109 which takes a form of Dictionaries 114. This waygeneric Phrase Renderers 109 can be created; for example, mapping givenXpaths to sentences, which are configurable. Another example ofconfiguration is the precision of numbers, for example, decimal placesafter comma to display, for given concepts.

The Report Transformer 104 is responsible for converting one DICOM SRreport to another, which may be used to create a boilerplate for thefinal report from a preliminary report, or for scanning a text-basedDICOM SR report to create a SR report with one text concept named“findings” and place all the report content in sentences. This report isnot “structured” itself but is written in DICOM SR format. An“intelligent” report transformer could convert such a report to a trulystructured one. The Reporting Engine 101 provides a way to configure ageneric Report Transformer 104 and stores such a configuration as aReport Transformation 107.

In such architecture, three concepts are separated—report definition,which is handled by the Report Editor 102 and stored as Report Templates105; how a report looks, which is handled by the Report Renderer 103 andstored as the Report Layout 106; and the report vocabulary, which ishandled by the Phrase Renderer 109 and configured by the Dictionary 114.In addition to this method, it is possible to have a generic ReportEditor 102, Report Renderer 103 and Phrase Renderer 109 that can handleall types of DSR's. The Reporting Engine 101 allows for the creation ofmore specialized components, to connect each triplet (Report Template105—Report Layout 106—Dictionary 114) and to store such connectedinformation in configuration by the use of the Reporting Contextdescribed further below.

The Application 100 which uses the Reporting Engine 101 has to implementa Reporting Context 113 interface that makes it possible for theReporting Engine 101 components to communicate with the external world.It provides a gateway for storing a report, sending a fax, sending anemail, retrieving information about report templates or layouts,retrieving information about current users and their roles. By thepresence of this interface, one can use the Reporting Engine 101 in manydifferent environments and with different back-end databases. All thatis required to implement this process is the Reporting Context 113 whichcan be considered as an adapter to connect with external environment.

A PACS lifecycle is counted in years and report definitions may evolvein time. However, it must be a possibility to amend or render olderreports despite software evolution. So each reporting software plug-inhas to be assigned a version and each version must be maintained by theReporting Engine and the “lazy-loading” of reporting software plug-inshave to be applied. When a viewer is loading no report plug-ins areloaded, and loading is deferred to the moment of report creation sinceat this moment it is known which report to create and thus whichappropriate report software plug-in would be needed. An alternative tothis approach consists of “eager loading” as opposed to “lazy loading”which entails loading all reporting software plug-ins together with theviewer, but this is not an efficient method.

FIG. 3 is a flow chart illustrating a preferred embodiment of a reportgraphical user interface sample structure of the present invention. FIG.3 illustrates a Report Editor Window 140 GUI that consists of a set ofMain Tabs 122. Each Main Tab 122 can consist of a set of Sub Tabs 123,or similar category delineation. Each Sub Tab 123 consists of a set ofHeaders 128 or Measurement Tables 125 (FIG. 4). A Header 128 defines agroup of related Concepts 129. The Header 128 also defines the relationbetween the Concepts 129, allowing only one concept to be chosen fromthe set (XOR relation, rendered as radio buttons (XOR—exclusive or) andsample rendition is radio buttons) or any concept to be chosen from theset (OR relation, rendered as checkboxes for example). Each Concept 129is rendered as a line in a Header 128 and represents one or severalDICOM SR concepts; each concept can consist of an arbitrary number ofGUI components (found in FIG. 4) like Label 131, EditBox 133, ComboBox132 or SpinEdit 134 actions. FIG. 4 illustrates how Comboboxes 132 maybe used for either choosing a value (for example, text, numerical orcode) from a given set, or to set the coded name of DICOM SR conceptrepresented by the Concept GUI 129. Each concept can add a phrase to thereport. This phrase is displayed in a popup hint-box when the useractivates the phrase box (for example, the user moves the mouse arrowover the concept line in the GUI). A Measurement Table 125 provides aconvenient way for entering a set of measurements. Each row represents asingle measurement. The table contains the following columns:measurement name, measurement value, measurement units, default ranges,and image mode. Measurement names and default ranges and optionally theimage mode are fixed in the report definition; the rest is entered bythe user. This GUI process allows for presenting and entering the set ofvalues in more lucid fashion than when using Header and Concepts,because the values are aligned into columns. If a value exceeds thedefault ranges, the whole row is marked as red and a corresponding iconor symbol signifies if the value exceeds the range or falls below therange.

FIG. 4 is a schematic view illustrating a preferred embodiment of areport editor graphical user interface structure of the presentinvention. In order to create report GUIs as described above, a GenericReport Editor Software Plug-in is developed and illustrated in FIG. 4.This novel method provides a way for creating the GUI definition withouthardcoding it in the application. However, if the GUI is not flexibleenough, for example, containing a graphical diagram, a custom-developedGUI can be developed and then merged with the definition. The ReportDefinition 120 is stored as a Report Template 105 and as a configurationfor the Report Editor 102 (See FIG. 2). The Report Definition 120reflects the report GUI, so it consists of Tabs 122 which consists ofSub Tabs 123, which consist of Subtab Components 124, which can beeither a Header 128 or a Measurement Table 125. Tabs 122, SubTabs 123and Headers 128 have the caption property as well as they might behidden without removing them from the Definition 120. A Header 128consists of a set of Concepts 129 and each Concept consists of severalComponents 130, each of which may be a Label 131, a ComboBox 132, anEditBox 133 or a SpinEdit 134. Each Concept 129 also has oneWriteHandler 141 which is a software component used for storing a DICOMconcept corresponding to a GUI Concept 129 and one ReadHandler 142 whichis responsible for “pulling” the value out of the source report andpopulating the GUI Concept. The software architecture permits customdevelopment for providing unique Read/Write Handlers 141, 142 or the useof a default Handler which makes the use of a DICOM Path as describedbelow. The main purpose of Generic Editor Software Plug-in is to providea GUI, as previously described in the Report Editor GUI, to store SRreports in given DICOM SR template and read reports created by it. Thereading of any SR report, even with a given template, is not a goal forthis Generic Editor Software Plug-in, although such an editor can beimplemented and deployed in the Reporting Engine 101.

The present invention allows a developer to use Generic Report EditorSoftware Plug-in “as-is,” providing only a suitable report definition,or they may incorporate their own Report Editor Software Plug-in byextending the generic one. This process is accomplished by extending itby:

-   -   1. Providing a different tabbed GUI that will be merged with the        GUI stored in the definition; This way a GUI with dynamic        diagrams may be created;    -   2. Providing unique Read/Write handlers;    -   3. Or, modifying the definition and updating the GUI in runtime,        which allows for creating tabs dynamically which may be suitable        for creating reports like for OB-GYN, where a tab for each fetus        may be created.

FIG. 5 is a flow chart illustrating a preferred embodiment of a reportgraphical user interface life cycle function of the present invention. Areport GUI life cycle is depicted in FIG. 5. First, a Report Definitionis stored in the Report Engine's configuration 150. Then, when there isneed to invoke the Report Editor GUI (for example, when amending orcreating a new report), the Report Definition is loaded into memory asan interconnected object tree 151. This tree can be further adjusted 152by providing custom software code, which can change the definition basedon the SR object to be amended. Thus, additional tabs/headers may becreated, or copied from an existing definition. Following the reportdefinition adjustment 152, the GUI window is created 153 based on theadjusted definition and optionally provided custom GUI. GUI merging isdone so each hard-coded tab or subtab is matched to the tab/subtabstored in the definition. Then, the newly created GUI is populated froma source report 154 to set the input fields to the values in the report.The Read Handlers are used to populate the report. The GUI and thedefinition can be further modified 155 by using a custom code, ifneeded, from a software report utility functions provided by theReporting Engine. Thus, for example, a tab for additional fetus may becreated on-demand in run-time. When a report is requested to be written,the Write Handlers are used to store the report in a DICOM SR format156. The report is then submitted to the PACS using the ReportingContext 110 provided by the application 100. Then the Report Editor GUIis destroyed 157 and the definition is unloaded from the memory 158.

FIG. 6 is a flow chart illustrating a preferred embodiment of astructured reporting path data structure of the present invention. InFIG. 6, the DICOM SR-path structure is illustrated. The DICOM SR-path isan address of a DICOM SR concept in a SR tree format, which is suitablefor retrieving the value of a given concept from the report, but it canalso be used to store such values in an appropriate place in the DICOMtree. The DICOM SR-path can be used as a convenient way to describe howthe report should be read/stored, and it is used as a default for theRead/Write Handler of the Report Editor described above. It is flexibleenough to describe most of the standard DICOM SR templates, and makes itsimpler to implement the GUI for report editors as described above.

FIG. 6 depicts a Unified Modeling Language (UML), which is an objectmodeling and specification language used in software engineering, classdiagram of the SR-path. FIG. 6 shows the classes comprising the SR-pathdata structure and relations between them. The SR-path can also bestored in text format using a language with grammar described withBackus Naur Form (BNF) notation or in Extensible Markup Language (XML)format defined with XML-schema. The SR-path 450 consists of a list ofAddress Cells 451. Each address cell describes a child of a given nodein a SR tree. When finding a concept represented by the last AddressCell instance in the path chain, a set of children is found using eachAddress Cell instance and the search is performed recursively further.The concept name of each SR node is compared to the concept nameattribute of the appropriate Address Cell object, so with the SR typeand the SR relation. The classes 452-456 are subclasses of the AddressCell class and they correspond to standard Structured Reports types (notall of them are depicted here). Their values are also compared (whengiven) during search procedure. Aside from having a simple path from theroot of the tree to the searched element, additional criteria may bespecified using the ‘where’ and ‘where not’ associations in the AddressCell. This association allows for specifying further constraints on thechildren. A condition is defined by a relative SR-path; evaluation ofsuch SR-path starts from the node currently being processed and if the‘where’ path is found—the criterion is fulfilled. In case of ‘where not’criterion the condition path has not to be present to satisfy thecondition. The conditions are interconnected using an “AND” relation.Below is a sample SR-path, describing a measurement written inconformance with DICOM standard template for Echocardiography procedurereport (TID 5200). The SR-path is written in simplified text grammar.The CONTAINER, CODE and NUM keywords are for describing the type of theconcepts, slash sign is for advancing to the next child level andbracket signs are for defining constraints. The example is trivializedand simplified because no relationship constraints are shown, humanreadable names are written instead of DICOM coded terminology and thereare no compound or multilevel constraints. An example is illustrated asfollows:

CONTAINER(name=‘Findings’)[CODE(name=‘finding site’, value=‘LeftVentricle’] / CONTAINER (name=‘Measurement Group’) [CODE (name=‘Imagemode’, value=‘2D’)] / NUM(name=‘LVVOL(d)’) [CODE(name=‘Method’,value=‘Teichholz’)]

To read a measurement using this SR-path, an algorithm would:

-   -   1. find a child(ren) of type CONTAINER with concept name        ‘Findings’ having a child of type CODE with concept name        ‘finding site’ and value ‘Left Ventricle’    -   2. for each node found in (1) it should find a child(ren) of        type CONTAINER having concept name of ‘Measurement Group’ having        children of type of CODE with concept name “Image mode” and        value of “2D”    -   3. for each node found in (2) it should find a child(ren) of        type NUM with concept name ‘LVVOL(d)’ having a child of type of        CODE which has concept name ‘method’ and the value ‘Teichholz’.        The NUM node is the measurement being looked for as it is the        last item on the path chain.

A similar algorithm is used for writing a value having a given SR-path.For subsequent child levels, it is checked if the level already existsin the SR tree and if not—it is created together with accompanying nodesfound in constraints. This is recursively repeated until reaching thelast component of the path.

It is crucial that only “equal” and “AND” relations are allowed. Suchrestriction is necessary for allowing the use of the SR-path for reportdefining purposes, not only for validation/read purposes. If it allowed“OR” relation, there would be ambiguity during writing process in themoment of writing node constraints. With AND relation, all constraintshave to be written to meet the constraint condition, but with ORrelation it would make less sense. The same applies when code values, ornumeric values are used in the constraints. Only comparisons using‘equal’ relation and comparing to constant values are permitted. Theconcept which location is described using such SR-path can be storedproperly in the SR format and all intermediate child nodes will becreated. The SR-path can also be used for report transformations (seeReport Transformer), and it can also be used with the generic PhraseRenderer for describing the dictionary key. The path is suitable fordescribing most of the standard SR templates.

SR-path can be parameterized to achieve yet more flexibility. EachAddress Cell attribute (and Address Cell's subclasses attributes) can beprovided directly—by giving the value of the attribute, or indirectly,by providing only parameter name. Such parameterized SR-path is a moregeneric template that can be customized at runtime by providing thevalues of parameters. For write operations all parameter's values mustbe provided. For read operations some of them may be not provided—insuch a case the constraints for searched elements will be loosened, theconstraints with values having not present parameter values are treatedas not existing ones. Thus the SR-path query may return more results.For each result the parameters not filled before search operation willbe filled by the search procedure. Below is example of parameterizedSR-path (similar to the previous example)

CONTAINER(name=‘Findings’)[CODE(name=‘finding site’, value=‘LeftVentricle’]/CONTAINER(name=‘Measurement Group’)[CODE(name=‘Image mode’,value=‘:mode’)]/NUM(name=‘LVVOL(d)’)[CODE(name=‘ Method’,value=‘:method’)]

The parameters are written here as the colon sign followed by theparameter name. For write operations all parameter values have to beprovided. So it can be set that parameter ‘mode’ has a value of ‘2D’ andparameter ‘method’ has the value of ‘Teichholz’. For read operations twocases are possible: all parameter values are provided (to 2D andTechholz respectively for the sake of the example); this way theLVVOL(d) done with 2D and Teicholz method is retrieved. Actually morethan one result may be returned if there is more LVVOL(d) parametersexisting in the report.

Some (or all) values for parameters are not provided. For example valuefor parameter ‘image mode’ is provided and value for parameter ‘method’is not given; in this case multiple results will be returned for anyLVVOL(d) done with 2D, and the return parameter ‘method’ will be filledin with appropriate method for each result. With given search result isassociated a set of names of return parameters, and with each parametername is associated a set of parameter values. This way it is possible toretrieve set of ‘method’ parameter values if there were more than onemethod modifier attached one LVVOL(d) measurement (such example makes nopractical sense, but the ability of getting set of parameter values isneeded for general case)

Another example of employing parameters in searches is to retrievenumeric values with return parameters. The following SR-path snippetshows this:

-   -   ‘NUM(name=‘LVVOL(d)’, value=‘:value’units=‘:units’)’

This makes sense only if there is only one result matching the SR-path,or only one units of measurement is used for particular parameter. Ifnot—a set of values and other set of units will be returned and therewill be no way of connecting them. In such a case, using returnparameters for getting the values is not advised. Processing nodeassociated with each search result to retrieve value and unit ofmeasurement should be applied.

The SR-path class 450 represents only a stored definition of an SR-path.It can be stored in any format or build in runtime. For actualfind/write operations SR path runtime interface 457 is used. Instancesof sample class implementing this interface—SRDocumentPath 459 arecreated for each SR path definition and structured report instance(represented here by SRDocument 458 interface). Apart from providingoperations for finding, writing and deleting nodes, the SR path runtimeinterface has the operations to manage set of input parameters inruntime, needed for operations. Find operations can be applied to theroot of the structured report (so the path is considered non-relative)as well as to other node in this report (so the path is consideredrelative). The same is true for delete and write operations. Writeoperation can work in three modes corresponding to behavior in case offinding node matching to the path already in the report. The writeoperation can:

fail if node described by path already exists

overwrite the existing one

create a sibling to the existing one

The delete operation can work in two modes:

delete only the node found in the path

delete also all preceding nodes in path if there are no other siblingnodes left in the report being worked on, on each respective level. Forexample path:

CONTAINER(name=‘Findings’)[CODE(name=‘finding site’, value=‘LeftVentricle’]/CONTAINER(name=‘Measurement Group’)[CODE(name=‘Image mode’,value=‘2D’)]/NUM(name=‘LVVOL(d)’)[CODE(name= ‘Method’,value=‘Teichholz’)]

The delete operation will first delete the last NUM item (if found).Then it will check if there is any child of Measurement Group nodeleft—if not it will delete also the ‘Measurement group’ container. Thenit will check if there is any child of Findings node left—if not it willdelete also the Findings container node. For delete operations, allparameter values must be provided.

In the DSR processing application there are several data work-flowsinvolved. Data (for example, measurement values) should be transmittedseamlessly from the procedure report generated by the modality or OCRengine, through the preliminary report to the final report. Each ofthese reports may and usually will have different structure. So, a wayof converting a report from one form to another is provided.

FIG. 7 is a flow chart illustrating a preferred embodiment of a reporttransforming algorithm of the present invention. The transformerprocessing algorithm as used in the Reporting Engine is depicted in FIG.7. When report creation of a given template is needed 200, the ReportingEngine searches for the transformation that could produce the desiredreport 201. Each Transformer 104 software plug-in is capable ofdetermining the output report template it creates. Then, the reportingengine “asks” each selected transformer for the ability of performingtransformation on a given set of already existing SR reports. Onlytransformers able to proceed with the given input data are selected 202.The set of possible transformations may be ambiguous (for example,having multiple preliminary reports yet the transformer allows theselection to convert one preliminary report to one final report). Insuch a case, the user is requested to choose the appropriatetransformation 203. The transformation is performed 204 and the ReportEditor Software Plug-in makes the conversion. In case of finding nosuitable report transformations, a new report is created by the ReportEditor Software Plug-in.

FIG. 7 illustrates an example of a Generic Report Transformer. In thisembodiment, the Generic Report Transformer would convert a SR report toXML document format, then apply an Extensible Style LanguageTransformation (XSLT), stored in the transformer configuration, and thenconvert back to the resulting XML document to SR format. However,another approach is more convenient with the use of SR-paths. In such anembodiment, a transformer is provided with two lists of SR-paths—onesource list and one destination list. Each element from the destinationlist corresponds to one element in the source list. When transforming areport, each pair source value is found in the source report usingsource SR-path and then written in the destination report usingdestination SR-path. This may be shown on the following example. Thetransformer is given 2 lists; source: (A/B, C/D) and destination (Q/W,X/Z). When it processes a report with single concept A/B—it will betransformed to report Q/W. The rule C/D->X/Z would not be launchedbecause the report does not contain a C/D branch. Had the reportcontained some other branch, like for example T/Y/U, it would bediscarded, because there is no rule for processing it. It should benoted that SR-paths can describe whole sub-tress as well as singlemeasurements, so whole branches of the source tree can be easily copied,working as a form of a ‘push’ transformation. However this processingdiffers from XSLT pattern based transform, and it is more convenient forworking with DICOM Structured Reports and copying selected measurements.XSLT is more powerful and generic but it is harder to provide a SRtransformation definition with this and the transformation definition isa mess. Additionally, such a report transformer has an SR document whichacts as a template for the resulting report. It has a SR tree with somepredefined branches already in it, to make it easier to createtransforms. The concepts populated from source reports are merged intothis predefined ‘skeleton’ report.

FIG. 8 is a flow chart illustrating a preferred embodiment of a reporttransforming algorithm of the present invention. FIG. 8 illustrates anImage to DICOM Structured Report (DSR) conversion engine. In theillustrated preferred embodiment, the Report Transformer 104 processessource DICOM structured reports and produces output structured reportswhich can be further modified using the Report Editor 102. It makes itpossible to populate measurements from a procedure report to the finalreport or populate certain data stored by the technician in thepreliminary report to the final report. In order to have it working, thesource reports have to be in DICOM SR format, and this works well whensource modality has the ability to produce such reports. In theembodiment in FIG. 8, the SR enabled DICOM modality 656 sends DICOMimages 651 together with optional DICOM reporting pages 652 and DICOM SRreports 654 to the PACS server 655. Some imaging modalities, forexample, ultrasound machines, like the Philips Sonos 5500, Philips HDI5000, Siemens Acuson and Siemens Sequoia 650, however, do not supportoutputting measurement values in DSR format—this pertains mainly forolder devices. They send only DICOM images and DICOM reporting pageswith measurements stored in bitmap format. This format is not suitablefor reading by machines, so the claimed Image to SR conversion engineprovides a format conversion from bitmap format to DICOM StructuredReports. So when a PACS server 655 receives a study from the modality itstores it and forwards to the Image to DSR conversion engine 653. Theconversion engine 653 may be implemented as a standalone DICOM entityand as such may accept input images using DICOM protocol, or may be justan internal part of the PACS server, or may fetch the source images froma WADO server given the set of links—the actual deployment is not asubject of this claim. Since OCR algorithm depends highly on the layoutof the source images, and thus on the modality vendor, several plug-ins657 may be deployed in the Conversion Engine 653, each for convertingimages coming from another type of the modality. The Conversion Engine653 performs the following steps:

-   -   (1) Asks each OCR plug-in if it can handle the study. The OCR        plug-in is free on how to implement this check; the easiest way        is to check for appropriate DICOM tags, but it may use image        recognition at this point.    -   (2) For each image, the selected plug-in checks to determine if        the image contain measurement data. It may choose only report        pages, or other images as well for further analysis.    -   (3) Having a set of suitable images, the OCR engine delegates        OCR work for a selected plug-in, which is supposed to produce a        set of DSR reports.    -   (4) The OCR engine sends produced reports back to the PACS        server

When implementing the OCR plug-in a developer can make use of a standardlibrary shared by the Conversion Engine 653 which makes it easier toperform image segmentation and font management. Since the nativelanguage for implementing such plug-ins is JAVA, the plug-in may useJava Advanced Imaging libraries, however nothings prevents implementingsuch plug-in in native CPU code.

It is important that the software plug-in should produce one of thestandard DICOM SR template like, for example, TID 5200 for UltrasoundAdult Echo Procedure Reports, because there will be no need to writeadditional code in the Report Transformer which can handle standardDICOM SR templates.

FIG. 9 illustrates an Image to DICOM Structured Report (DSR) conversionengine. In this preferred embodiment the Report Transformer 104processes source DICOM structured reports and produces output structuredreports that can be further modified using Report Editor 102. It makesit possible to populate measurements from a procedure report to thefinal report or populate certain data stored by the technician in thepreliminary report to the final report. In order to have it working thesource reports have to be in DICOM SR format, and this works well whensource modality has the ability to produce such reports. In suchembodiment SR enabled DICOM modality 656 sends DICOM images 651 togetherwith optional DICOM reporting pages 652 and DICOM SR report(s) 654 tothe PACS server 655. Some imaging modalities (example, ultrasoundmachines, like the Philips Sonos 5500, Philips HDI 5000, Siemens Acusonand Siemens Sequoia) 650 however don't support outputting measurementvalues in DSR format—this pertains mainly for older devices. They sendonly DICOM images and DICOM reporting pages with measurements stored inbitmap format. This format is not suitable for reading by machines, sothe claimed Image to SR conversion engine provides a format conversionfrom bitmap format to DICOM Structured Reports. So when a PACS server655 receives a study from the modality it stores it and forwards to theImage to DSR conversion engine 653. The conversion engine may beimplemented as a standalone DICOM entity and as such may accept inputimages using DICOM protocol, or may be just internal part of the PACSserver, or may fetch the source images from WADO server given the set oflinks—the actual deployment is not a subject of this claim. Since OCRalgorithm depends highly on the layout of the source images (and thus onthe modality vendor), several plug-ins 657 may be deployed in theConversion Engine, each for converting images coming from another typeof the modality. The Conversion Engine performs the following steps (seeFIG. 9):

-   -   1. Asks each OCR plug-in if it can handle the study 658. The OCR        plug-in is free how to implement this check; the easiest way is        to check for appropriate DICOM tags, but it may use image        recognition at this point    -   2. For each image the selected plug-in checks if the image        contain measurement data 659. It may choose only report pages,        or other images as well for further analysis.    -   3. Having a set of suitable images, OCR engine delegates OCR        work for selected plug-in, which is supposed to produce a set of        DSR reports. The Conversion engine publishes a library which        makes it easier to implement the most typical OCR processing.        Such steps are presented below:        -   3.1. The frame is divided onto segments in segmentation            process 660. Segments are hierarchical, which corresponds to            the most commonly met case where for example header segments            are related or contain subheader segments and/or            measurements segment, and a measurement segment contains a            label segment, value segment and a units of measurement            segment. The library makes it easier to do segmentation            because it contains several segmentation routines and            publishes a set of standard segment classes.        -   3.2. The value object extraction is performed 661. The            library provides support for character recognition based on            a font database (appropriate set of glyphs is provided by            the plug-in). It also provides a standard value object            classes for headers (which may contain other headers and/or            measurements) and measurement value objects (which contain a            label, value and a unit of measurement)        -   3.3. The conversion of value object to DICOM Structured            Report is performed 662. If a plugin uses standard value            objects, this step may be performed entirely by the            Conversion Engine. If so—it uses an external configuration            mapping file 663 which maps a native modality measurement            (in context of headers and/or subheaders it is located in)            into a SR-path.    -   4. The OCR engine sends produced reports to a PACS server. It        can be configured to sent it back to the server that sent the        study.

When implementing the OCR plug-in a developer can make use of a standardlibrary shared by Conversion Engine which makes it easier to performimage segmentation and font management. Since the native language forimplementing such plug-ins is JAVA, the plug-in may use Java AdvancedImaging libraries, however nothings prevents implementing such plug-inin native CPU code.

It is important that the software plug-in should produce one of thestandard DICOM SR template (like TID 5200 for Ultrasound Adult EchoProcedure Reports), because there will be no need to write additionalcode in Report Transformer which can handle standard DICOM SR templates.In such a case the OCR engine can be also used as a standalone box forconverting images to standard DICOM Structured reports so other vendorsmay populate the values from non DSR enabled modalities, without theneed of implementing OCR processing by themselves.

The invention being thus disclosed and illustrative embodiments depictedherein, further variations and modifications of the invention will occurto those skilled in the art. All such variations and modifications areconsidered to be within the scope of the invention, as defined by theclaims appended hereto and equivalents thereof.

Additional advantages and modification will readily occur to thoseskilled in the art. The invention in its broader aspects is thereforenot limited to the specific details, representative apparatus, and theillustrative examples shown and described herein. Accordingly, thedepartures may be made from the details without departing from thespirit or scope of the disclosed general inventive concept.

1. (canceled)
 2. A method for implementing a structured clinicalreporting system over the Internet, the structured clinical reporthaving a DICOM Structured Reporting format, and the Internet adapted towork in conjunction with hypertext transfer protocol (HTTP) forconnecting a server and multiple workstations via the Internet, themethod comprising the steps of: (a) providing communication between aworkstation and the server via the Internet,3 (b) adapting a reportingsystem to have a reporting engine, the reporting engine is in operativecommunication with the workstation, an image viewer-editor and theserver, (c) providing the workstation for creating the clinical report,signing the clinical report, rendering the clinical report, transmittingthe clinical report to and from the server via the Internet, (d)providing the workstation for manipulating a study list stored on theserver, (e) providing a picture archiving and communications system(PACS) server, (f) providing communication between the PACS server and adatabase server, (g) providing communication between the PACS server anda viewer and the workstation over the HTTP protocol, (h) providingcommunication between the PACS server and an imaging modalities using aDICOM interface, such as the PACS server is in operative communicationwith imaging modalities via DICOM protocol and is in operativecommunication with the database, whereby the workstation comprising theviewer further comprises the reporting engine, the image viewer-editorand the study list viewer is in operative communication with the PACSserver via the Internet using the HTTP protocol.
 3. The method forimplementing a structured clinical reporting system over the Internet asdefined in claim 2 wherein the image viewer-editor is a DICOM viewerhaving rich client characteristics.
 4. The method for implementing astructured clinical reporting system over the Internet as defined inclaim 2 wherein the workstation provides the automatic downloading,installing and running of the rich-client viewer.
 5. The method forimplementing a structured clinical reporting system over the Internet asdefined in claim 2 wherein the image viewer-editor is a rich clientcapable of being installed remotely.
 6. The method for implementing astructured clinical reporting system over the Internet as defined inclaim 2 wherein the image viewer-editor is a DICOM viewer implemented inJAVA language having rich client characteristics.
 7. The method forimplementing a structured clinical reporting system over the Internet asdefined in claim 2 wherein the image viewer-editor is a DICOM viewerautomatically downloaded and installed using Java Web Start technology.8. The method for implementing a structured clinical reporting systemover the Internet as defined in claim 2 wherein the study list viewer isimplemented in WWW-based, thin-client technology.
 9. The method forimplementing a structured clinical reporting system over the Internet asdefined in claim 2 wherein the study list-viewer comprises a graphicaluser interface for displaying patient exams, studies and informationlisted by specific category including chronological order and status.10. The method for implementing a structured clinical reporting systemover the Internet as defined in claim 2 wherein access to the databaseis from a remote workstation to the PACS server such that databasetraffic between the remote workstation and the database server istunneled over secure HTTP protocol.
 11. The method for implementing astructured clinical reporting system over the Internet as defined inclaim 2 wherein a DICOM object is downloaded from the PACS server to theinterface viewer using WADO protocol.
 12. The method for implementing astructured clinical reporting system over the Internet as defined inclaim 2 further comprising Web Services for providing communicationbetween the PACS server and a client-side, rich-client viewer.
 13. Themethod for implementing a structured clinical reporting system over theInternet as defined in claim 2 wherein the workstation is a computer.14. The method for implementing a structured clinical reporting systemover the Internet as defined in claim 2 wherein the workstation consistsof a central processor unit and a random access memory.
 15. The methodfor implementing a structured clinical reporting system over theInternet as defined in claim 2 wherein the picture archive communicationsystems (PACS) comprises a central data storage device.
 16. The methodfor implementing a structured clinical reporting system over theInternet as defined in claim 2 wherein the clinical reports are storedand transmitted using a DICOM Structured Report format.
 17. The methodfor implementing a structured clinical reporting system over theInternet, the structured clinical report having a DICOM StructuredReporting format, and transmitted over the Internet over HTTP protocolbetween multiple workstations and the server via the Internet as definedin claim 2, wherein the step of adapting a reporting system to have areporting engine comprises the steps of: (a) sending images, optionalreporting pages and structured reports from DICOM modality to the PACSserver, where the images, optional reporting pages and structuredreports are defined as a study, (b) storing the study in the PACSserver, (c) forwarding the study from the PACS server to an image-DSRconversion engine, (d) determining whether the image-DSR conversionengine can make the appropriate conversion of the study, (e) extractingmeasurement information from the DICOM modality images, (f) determiningif the study contains measurement data for further analysis; ifconversion is appropriate, populating the study data into the report inDSR format; if conversion is not appropriate, then the report opens inDSR format without data, (g) storing the values acquired in the DICOMstructured report format, and (h) storing the produced structuredclinical report in the PACS server.
 18. The method for implementing astructured clinical reporting system over the Internet as defined inclaim 16 wherein optical character recognition is used to obtainmeasurements from the study list images of the DICOM modality.
 19. Themethod for implementing a structured clinical reporting system over theInternet as defined in claim 16 wherein optical character recognition isused to obtain measurements from the study list clips of the DICOMmodality.
 20. The method for implementing a structured clinicalreporting system over the Internet as defined in claim 16 wherein theDICOM modalities comprise one or more of ultrasound, x-ray, computertomography, positron emission technology, nuclear imaging andfluoroscopy.
 21. The method for implementing a structured clinicalreporting system over the Internet as defined in claim 16 wherein theOCR data is converted to a DICOM Structured Report (DSR) coding schema.22. The method for implementing a structured clinical reporting systemover the Internet as defined in claim 16 wherein the extractedmeasurement data from the DICOM modality comprises one or more of names,values, units of measurements, and patient information.
 23. The methodfor implementing a structured clinical report system over the Internet,the structured clinical report having a DICOM Structured Reportingformat, and transmitted over the Internet using HTTP protocol betweenmultiple workstations and a server via the Internet comprising the stepsof: (a) adapting a reporting system to have a reporting enginecomprising a generic report transformer, (b) determining a report typeto be created having given a set of source reports to populate datafrom, (b) searching transformations that could produce the desiredreport type to determine a set of one or more transformations that canproduce the desired report from a given set of source reports, (c)narrowing the set of transformations by applying the specific sourcereport criteria, (d) providing a user selection of a source reportselected from the group of populate from, convert and transform, (e) ifno report type can be identified, creating a report to accommodate thespecific source report criteria, and (f) creating the requested reporttype from the set of transformations.
 24. A method for implementing astructured clinical report system over the Internet, the structuredclinical report in operative association with a Graphical User Interface(GUI) to create or amend a report having a plurality of parts, themethod comprising the following steps: (a) providing a set of structuredmain tabs corresponding to a part of the report being created, (b)providing that each structured main tab is divided into one or moresub-tabs, (c) providing that each sub-tab further comprises an arbitrarynumber of at least one of headers, measurement tables and fast searchcode lists, (d) providing that each header further comprises anarbitrary number of concepts to be selected mutually or non-exclusivelywithin the header such that mutual selection is implemented with GUIelements while non-exclusive selection is done with GUI elements, (e)providing that each concept comprises an arbitrary number of GUIelements, and (f) providing that each concept corresponds to at leastone concept in the DICOM SR template.
 25. The method for implementing astructured clinical report system over the Internet for implementing theGUI as defined in claim 24 wherein the GUI elements comprise labels,edit boxes, spinners and combo boxes.
 26. The method for implementing astructured clinical report system over the Internet for implementing theGUI as defined in claim 24 further comprising a GUI definition stored inan external configuration file as a report template.
 27. The method forimplementing a structured clinical report system over the Internet forimplementing the GUI as defined in claim 24 further comprising: (a) acontext help user interface element such that the content depends on thecurrent sub-tab being displayed and the content changes dynamicallyafter switching, and (b) the content of the context help user interfaceelement is stored together with a report template.
 28. The method forimplementing a structured clinical report system over the Internet forimplementing the GUI as defined in claim 24 further comprising the stepsof: (a) loading and validating the GUI definition into the computermemory where a tree-like structure of a template merges into a GUI formsupplied by a report editor plug-in, (b) adjusting the GUI definitiondynamically by a report editor plug-in based on the report being edited,(c) creating the GUI components, (d) populating the GUI components fromthe source report, (e) allowing the report editor plug-in to modify theloaded report template such that the GUI is altered on the fly based ona user's input, and (f) populating the report by taking information fromthe GUI elements and storing them in specific places in the DICOM SRreport as defined by the report template.
 29. A method for implementinga system for automatic population of values of parameters acquired by animaging modality into a DICOM structured report using optical characterrecognition, comprising the steps of: (a) providing a pluggable softwareextraction engine that accepts DICOM objects from another DICOMapplication entity, (b) providing a pluggable software extraction enginehaving a plug-in chooser that determines which software plug-in shouldbe used to extract data values from a given study, (c) providing a setof software plug-ins in active communication with an engine, the enginebeing able to recognize the values from at least one of the bitmap imageand the reporting page produced by a DICOM imaging modality of a givenvendor, and (d) providing a pluggable software extraction engine inoperative communication with a PACS server to store produced DICOMstructured reports for further distribution.
 30. The method forimplementing a system for automatic population of values of parametersacquired by an imaging modality into a DICOM structured report usingoptical character recognition as defined in claim 29 further comprisingthe steps of: (a) providing a pluggable software extraction enginehaving an image filter to sort the appropriate images with measurementfor further analysis, (b) providing a segmentation block for separatingthe logical parts of at least one of an image and a report page, whereinthe logical parts comprise visual segments, headers, measurement names,measurement values and units of measurement, (c) providing a valueobject extraction block for recognizing the semantics of a foundsegment, the segment comprising alpha-numeric data and numeric data suchthat the data is stored in structures defined as value objects, (d)providing a value object to DICOM SR format conversion block forserializing the value objects, and (e) mapping from extracted valueobjects to DICOM SR concepts by an external configuration file.
 31. Astructured clinical reporting system for use over the Internet, with astructured clinical report having a DICOM Structured Reporting format,and the Internet adapted to work in conjunction with hypertext transferprotocol (HTTP) for connecting a server and multiple workstations viathe Internet, the system comprising: (a) a workstation in communicationwith the server via the Internet, (b) a reporting system comprising areporting engine, the reporting engine is in operative communicationwith the workstation, an image viewer-editor and the server, (c) theworkstation for creating the clinical report, signing the clinicalreport, rendering the clinical report, and transmitting the clinicalreport to and from the server via the Internet, (d) the workstation formanipulating a study list stored on the server, (e) a picture archivingand communications system (PACS) server in communication with a databaseserver, (f) the PACS server in communication with a viewer and theworkstation over the HTTP protocol, (g) the PACS server in communicationwith an imaging modalities using a DICOM interface, such as the PACSserver is in operative communication with imaging modalities via DICOMprotocol and is in operative communication with the database, wherebythe workstation comprising the viewer further comprises the reportingengine, the image viewer-editor and the study list viewer is inoperative communication with the PACS server via the Internet using theHTTP protocol.